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® Space management system for a data access system of a file access processor. 



® A Space Management System for a Data Access 
System (14) of a File Access Processor (12) for 
servicing requests (10) from a set of Application 
Support Processors, which can exist in a global 
network, with each Application Support Processor 
. sharing access to data in files stored by the File 
access Processor (12). The File Access Processor 
(12) manages access to a set of data files and 
Information about files held in file directories, which 
allow for managing file collections, can relate to each 
other hierarchically, and may be shared. Each Ap- 
plication Support Processor also maintains therein 
0^an internal cache of file information to improve per- 
^formance by reducing communications required with 
^the File Access Processor (12) for information about 
^ files. The RIe Access Processor (12) provides the 
00 Application Support Processors with information for 
^updating and maintenance of local caches of direc- 
^tory and file description information through a cen- 
COtralized accumulation and distribution of cache 
Q change notifications. 

The Space Management System manages file 
Si space assigned to each Application Support Proces- 
sor and supports the space management functions 
of. adding space, deleting space, setting thresholds 



for limit warnings, querying space, charging space 
used, warning notifications, crediting space freed, 
and permitting file spaces to be shared by more 
than one application support processor. 
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© Space management system for a data access system of a file access processor. 



@ A Space Management System for a Data Access 
System (14) of a Fiie Access Processor (12) for 
servicing requests (10) from a set of Application 
Support Processors, wliich can exist in a global 
network, with each Application Support Processor 
sharing access to data in files stored by the File 
access Processor (12). The RIe Access Processor 
(12) manages access to a set of data files and 
<M information about files held in file directories, which 
fallow for managing file collections, can relate to each 
other hierarchically, and may be shared. Each Ap- 
CO plication Support Processor also maintains therein 
00 an internal cache of file information to improve per- 
^formance by reducing communications required with 
r-the RIe Access Processor (12) for information about 
^ files. The RIe Access Processor (12) provides the 
O Application Support Processors with information for 
^ updating and maintenance of local caches of direc- 
1 1 1 tory and file description information through a cen- 
tralized accumulation and distribution of cache 
change notiftcations. 
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The Space Management System manages file 
space assigned to each Application Support Proces- 
sor and supports the space management functions 
of, adding space, deleting space, setting thresholds 
for limit warnings, querying space, charging space 
used, warning notifications, crediting space freed, 
and permitting file spaces to be shared by more 
than one application support processor. 
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SPACE MANAGEMENT SYSTEM FOR A DATA ACCESS SYSTEM OF A FILE ACCESS PROCESSOR 



The present invention relates generally to a 
Space Management System which forms a part of 
a Data Access System of a RIe Access Processor. 
A RIe Access Processor services requests from a 
set of Application Support Processors, which can s 
exist in a global network, with each Application 
Support Processor sharing access to data in files 
stored by the RIe Access Processor. Application 
Support Processors may operate asynchronously, 
sharing the set of file resources managed by one io 
or more RIe Access Processors. A RIe Access 
Processor manages access to a set of data files 
and information about files held in file directories 
therein. RIe directories allow for managing file col- 
lections, can relate to each other hierarchically, and is 
may be shared. The RIe Access Processor also 
maintains therein a set of catalogs, which are re- 
positories of information in the File Access Proces- 
sor for its own internal use, and which are not 
available and accessible to Application Support 20 
Processors, as are the data files and directories. 
Each Application Support Processor also maintains 
therein an internal cache of file information to im- 
prove performance by reducing communications 
required with the RIe Access Processor for in- 2s 
formation about files. The RIe Access Processor 
provides the Application Support Processors with 
information for updating and maintenance of local 
caches of directory and file description information 
through a centralized accumulation and distribution 30 
of cache change notifications. 

More particularly, the present invention relates 
to a Space Management System which manages 
file space assigned to each Application Support 
Processor and supports the space management 35 
functions of adding space, deleting space, setting 
thresholds for Hmrt warnings, querying space, 
charging space used, warning notifications, credit- 
ing space freed, and permitting file spaces to be 
shared by more than one Application Support Pro- 40 
cesser. 

For the Prior Art discussion herein, the features 
of the present Data Access System are compared 
with features of two previous IBM systems, a 
SQLDS system, and a VM Minidisk File System. 45 

The SQLDS system is based on a substan- 
tially different system design providing compiled 
access routines which are compiled and executed, 
as opposed to the present system which provides 
interpretive request routines which are specifically 50 
designed to accomplish particular functions. 

The SQLDS system does not provide for an 
internal cache of file information similar to the 
present invention. 

Moreover, in the SQLDS system changes by 



an updater become available to other users before 
the changes are committed. In the present system 
changes are not available to other Application Sup- 
port Processors until the work unit is committed 
successfully. Each Application Support Processor 
retains the version of the file obtained when the file 
was initially accessed. 

The SQUDS system also does not provide for 
on- line data space management, and provides no 
warning as the SQUIDS equivalent of file space 
thresholds are approached. Dynamic changes to 
space limits are not provided, and the system can 
only provide for migration to new data base space. 
The SQUDS system basically represents an en- 
tirely different approach to recognition of space 
limits based on different requirements. The 
SQUDS system provides an immediate recognition 
when a consumption limit is reached, whereas DAS 
Space Management permits temporarily exceeding 
limits (until time of commit), such that only perma- 
nent space consumption is subject to enforced 
limits. 

The VM Minidisk RIe System does not provide 
for sharing of files or for a hierarchical directory 
support. There is no provision for globally main- 
tained cache information, and no provision for work 
units (requires keeping temporary copies of old 
versions of files for example). The VM Minidisk File 
System does not provide for sharing of data, and 
for support of separate caches. 

The VM Minidisk File System also has no 
provision for space management similar to the 
present invention, and only provides for mini-disks 
(virtual disks implemented as contiguous segments 
of real disks). The system does not provide a 
capability for on-line administration of space 
(changes to available space, limits, etc). Since 
space is directly associated with a contiguous stor- 
age assignment, an expansion requires a reassign- 
ment to another (larger) minidisk, and physical 
transfer of data files leading to delays, fragmenta- 
tion of space, administrative burdens, etc. More- 
over, the sharing of minidisks is haphazard and 
awkward. No concurrency controls are provided for 
synchronizing multiple writers (unpredictable re- 
sults). After updates, readers must re-access the 
minidisk or risk unpredictable results (loss of data 
integrity). Moreover, no space thresholds are pro- 
vided. 

In the VM Minidisk Rie System access au- 
thorization is controlled at the minidisk level, 
whereas the present system controls access at the 
file level which provides greater granularity-finer 
control. 

Accordingly, it is the object of the present 
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invention to provide a Space Management System 
for a Data Access System of a Rle Access Proces- 
sor as described hereinabove which manages file 
space assigned to each application support proces- 
sor and supports the space management functions 5 
of adding space, deleting space, setting thresholds 
for limit waming. querying space, charging space 
used, warning notifications, crediting space freed, 
and permitting file spaces to be shared by more 
than one application support processor. This object io 
of the invention is accomplished by the features of 
claim 1. Further advantages of the Invention are 
characterized in the subclaims. 

in accordance with the teachings herein, the 
present invention provides a Space Management 75 
System which is provided with access to a Space 
Catalog which records therein a record for each 
Application Support Processor representing logical 
file space that is assigned thereto. The Data Ac- 
cess System includes a Global Control structure 20 
which is maintained permanently for all activations 
of the Data Access System, and which anchors and 
provides a basis for locating Rle Space Control 
Blocks which maintain file space information in 
temporary storage, with each Rle Space Control 25 
Block being initially created from a Space Catalog 
record when a work unit is initiated for a particular 
Application Support Processor. Moreover, the Data 
Access System updates the record in the Space 
Catalog for the particular Application Support Pro- 30 
cesser when the work unit Is finished and commit- 
ted. 

In accordance with further details herein, mul- 
tiple Application Support Processors can consume 
space in a file space concurrently, and the Data 3^ 
Access System and Space Management System I 
enforce and support a common set of space con- j 
sumption limits and thresholds. Moreover, in the ; 
system, one Application Support Processor can 
authorize another Application Support Processor to 40 
share its file space. When an Application Support 
Processor initiates file space consumption in its ; 
own file space, the Rle Space Control Block ere- | 
ated during activation initiation is utilized for space 
management. When file space consumption is in a 45 
file space owned by another Application Support 
Processor, the initiating Application Support Pro- 
cessor utilizes the file Space Control Block created 
during the activation of the owning Application Sup- 
port Processor. Moreover, if the owner is not ac- so 
tive, a Rle Space Control Block is created by the 
first non-owner that utilizes the file space. 

It is an object of the Space Management Sys- 
tem of the present Invention to minimize the 
periods of non-concurrency for multiple Application 55 
Support Processors participating in updates to sep- 
arate files in a file space, in this system write locks 
are utilized to prevent concurrent changes to the 



same file. However, concurrent changes to different 
files in a file space should be allowed except 
during the period of Space Catalog update and 
commit of a work unit. The Space Management 
System is designed to allow Space Catalog change 
coordination between contending Application Sup- 
port Processors in such a manner as to maximize 
concurrency. 

The Space Management System accomplishes 
these system objections by the sequence of oper- 
ations at commit time. Initially, all catalogs are 
updated except the Space Catalog. Write locks 
exist on individual files, and are held until the 
commit is completed. A commit latch on an FSCB 
serializes commits of the Space Catalog changes. 
The FSCB latch is only held while doing the com- 
mit call to the Space Access System, thereby 
minimizing the period of non-concurrency for writ- 
ers to a particular file space. 

The basic sequence of operations at commit 
time is: 

a. Update all catalogs except the Space 
Catalog. 

b. Update the Space Catalog from FSCBs, 
latching the FSCBs. 

c. Invoke the Space Access System to com- 
mit the catalog and file changes. 

. d. Release the FSCB latch. 

This results in minimizing the period of non- 
concurrency for multiple Application Support Pro- 
cessors participating in updates to separate files in 
a file space. 

In accordance with the details of a disclosed 
embodiment herein, the Rle Space Control block 
for an Application Support Processor includes 
fields for, SPACE LIMIT which is the total space 
permitted for files, SPACE THRESHOLD which is a 
percentage of the space limit, SPACE CURRENT- 
LY CONSUMED which is updated for each file 
request that affects space consumption and is uti- 
lized to determine if the space threshold has been 
reached. SPACE COMMITED which is updated 
when the work unit is committed, and Rle Space 
Control Block LATCH which is used to synchronize 
changes to the space catalog. 

Additionally, for controlling the release of a Rle 
Space Control Block, an activity counter is main- 
tained in each File Space Control Block which is 
incremented by one for each activity initiated that 
involves a change in space consumption and de- 
cremented by one for each committed or termi- 
nated activity of that File Space Control Block. The 
File Space Control Block is finally released only 
when its activity counter goes to zero, which re- 
tains the Rle Space Control Block while it is ex- 
pected to be reused or currently active. 

In accordance with further details of the dis- 
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closed embodiment, the Data Access System also 
builds Local Control structures, one for each activa- 
tion of the Data Access System by a particular 
Application Support Processor. The Local Control 
structure provides a basis for locating a File Con- t 
trol Block which is used to retain information about 
a particular file while it is being accessed by a 
local activation of an Application Support pnDces- 
sor. The RIe Control Block has particular fields for 
space management, including a locator for the Hie n 
Space Control Block that is set when the file ac- 
cess is initiated, and used for rapid reference to the 
Rl8 Space Control Block thereafter. In greater par- 
ticularity, the RIe Control Block also includes fields 
for SPACE CONSUMED-CURRENT REQUEST 7s 
which is the change in space consumption caused 
by the completion of the most recent request 
against the file represented by this RIe Control 
Block, and SPACE CONSUMED-CURRENT WORK 
UNIT which is the change in space consumption 20 
caused by all changes to the file represented by 
this RIe Control Block in the cun-ent work unit 

The global control structure also includes a RIe 
Space Control Block hash table by which a RIe 
Space Control Block of a particular Application 25 
Support Processor can be located. 

Additionally, when a particular file access is 
completed successfully, a Woric Request Block is 
built containing information required for updating 
RIe Space Control Blocks and the Space Catalog 30 
records. Information is transferred from the RIe 
Control Block to the Work Request Block, and then 
the RIe Control Block is released. The Work Re- 
quest Blocks are used to retain information that is 
needed to update the Space Catalog for changes in 35 
space management information when the work unit 
is successfully completed and comnnltted. A sepa- 
rate Work Request Block is provided for each 
record In each catalog that must be updated. 

In greater detail, the Work Request Block in- 40 
eludes fields for. SPACE CONSUMED-CURRENT 
WORK UNIT which is the change in space con- 
sumption caused by all changes to the file repre- 
sented by this Work Request Block in the current 
work unit. REQUEST TYPE which is an encoding 45 
of the type of request that caused the Work Re- 
quest Block generation. PARAMETER VALUE 
which is used to hold the new space limit or space 
threshold for add-space, delete-space. and change- 
threshold requests so that it is available for modify- so 
ing the RIe Space Control Block and Space Cata- 
log at commit time, and SPACE CATALOG 
RECORD which is a copy of the Space Catalog 
record read into this area in preparation for selec- 
tively updating it. 55 

Moreover, the local control structure also pro- 
vides a basis for locating UNDO Lists which are 
used to save the status of RIe Space Control 



Blocks at the beginning of the current work unit so 
that the RIe Space Control' Blocks can be restored 
in the event of a failure in updating the Space 
Catalog during commit processing. 

In accordance with the teachings herein, the 
Space Management System supports a technical 
approach which presents a clear separation of 
functions to permit high performance, allowing easy 
maintenance and extensibility, while supporting the 
required functions. 

The control structures of the Data Access Sys- 
tem support the following particular features of the 
design. 

1 . DAS Global Control anchor for all global 
control structures, one for all activations of the 
DAS. 

2. DAS Local Control anchor for all DAS 
local control structures, one per activation of the 
DAS by an ASP. 

3. Work Request Blocks (WRBs) support de- 
ferred updates of catalogs, space consumption val- 
ues, and cache updates. 

4. RIe Space Control Blocks (FSCBs) sup- 
port dynamic threshold warnings and space con- 
sumption limits shared by all users of a file space. 

5. Cache structures in support of the central 
cache maintenance capability. 

The design of the Data Access System pro- 
vides structures for the following. 

1. Maintenance of local caches of directory 
and file description information through centralized 
accumulation and distribution of cache change no- 
tifications. 

2. Permanent storage in the form of catalogs 
for retaining shared infonnation about files, direc- 
tories, and control Information. A separate access 
method and storage facility is utilized for these 
catalogs from that utilized for file data, permitting 
flexibility in access to catalog information (access 
required only occasionally), while retaining high 
performance In the access to file data. 

3. Permanent storage and retrieval of file 
data blocks. 

4. Fast path processing for each request 
type through Individual and separate request pro- 
cessing routines, deferred updates to catalogs, and 
judicious balancing of in-line with centralized ser- 
vices. 

5. Services covering routing, response for- 
mulation and buffer management catalog access, 
storage management concurrency controls, etc. 
that are available for request handling routines, with 
minimal environmental switching (in-line or fast 
path). 
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6. Grouping requests into work units that can 
be subject to reversal (back-out of changes) in the 
event of a failure and control when a second writer 
to a common file can gain access. 

7. Concurrent activations, each servicing a 
logical grouping of file requests (supports sharing). 

8. Previewing of catalog changes whereby 
the originating Application Support Processor sees 
changes before they are committed (end of work 
unit), while other Application Support Processors 
do not have access to them until after the commit. 
This is made possible through deferred updates of 
catalogs and in-filght search of WRBs before cata- 
log reads. 

9. On-line file space management with con- 
sumption limits and thresholds whereby more than 
one ASP can concurrently consume space In the 
same file space and experience the same 
limits/thresholds. Also supports on-line administra- 
tion (changes in limits, thresholds, new file space 
etc.). 

The DAS Cache Management component is 
provided for maintaining local caches in each Ap- 
plication Support Processor which contain the cur- 
rent status of file information for cached directories. 
Cache Management utilizes a centralized collection 
of cache change information, along with facilities 
for recording and distributing the changes to the 
appropriate Access Support Processors, and in- 
cludes: 

1. A set of control structures for recording 
the information. 

2. A set of functions for performing the re- 
quired work. 

3. Control flow descriptions, relating Cache 
Management with other components of DAS. 

The DAS cache management design provides 
for data sharing and high performance, and more 
specifically: 

1 . Permits each Application Support Proces- 
sor to see directory changes, even those made by 
others on a timely basis. 

2, Concurrency controls required for the gio- 4S 
bal control structures that are required to support 

the function. 

3- Piggyback cache change notifications with 
normal responses. 

4. Non-replicated centralized change so 
records, Directory Change Refresh Blocks (DCRBs) 
minimize storage. 

5. Deferred recording of changes until the 
successful end of a work unit. 

55 

The DAS Space Management component pro- 
vides for support of on-line control of file space 
consumption limits in an environment where mul- 



tiple ASPs can consume space in a repository (file 
space) concurrently, while enforcing and supporting 
a common set of space consumption limits and 
thresholds, and includes. 

1. A set of control structures for recording 
the limits, thresholds, and other control inforrnation 
for each active file space. 

2. A set of functions for performing the re- 
quired work. 

3. Control flow descriptions, relating Space 
Management with other components of DAS. 

4. On-line setting and changes to consump- 
tion limits for individual file space. 

5. On-line setting and changes to threshold 
levels for warnings. 

6. Dynamic recording of space consumption 
(at commit time). 

7. Dynamic reporting of threshold levels 
reached for each file write (hence the particular 
need for FSCBs). 

8. Coordinated commit of Space Catalog 
changes with other work unit updates to catalogs 
etc. in such a way as to maximize concurrency. 

9. Capability for backing out changes in a 
consistent manner in the event of a failure. 

The foregoing objects and advantages of the 
present invention for a Space Management System 
for a Data Access System of a File Access Proces- 
sor may be more readily understood by one skilled 
in the art with reference to the following detailed 
description of a preferred embodiment thereof, tak- 
en in conjunction with the accompanying drawings 
wherein like elements are designated by identical 
reference numerals throughout the several views, 
and in which: 

Figure 1 illustrates the relationships between 
the major subcomponents of the Data Access Sys- 
tem, as well as the relationships between it and the 
other two components of the RIe Access Proces- 
sor, the Service System and the Storage Access 
System; 

Rgure 2 shows the major control structures 
of the Data Access System; 

Figure 3 illustrates the set of control struc- 
tures which are relevant to the Space Management 
Subcomponent; 

Figure 4 shows pertinent fields for Space 
Management in the FSCB, FCB. WRB. and UNDO 
List; 

Figure 5 illustrates the flow of control and 
data which occurs at the completion of a work unit 
(commit or rollback); 

Figure 6, 7 and 8, when placed together with 
Rgure 6 on top. Figure 7 in the middle, and Figure 
8 on the bottom, illustrate a logic flow diagram of 
the COMMIT operation supported by Space Man- 
agement; 
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Figure 9 illustrates a logic flow diagram of 
the ROLLBACK operation supported by Space 
Management; 

Rgure 10 illustrates a logic flow diagram of 
the UNDO operation supported by Space Manage- 
ment; and 

Rgure 11 illustrates a logic flow diagram of 
the UNLATCH operation supported by Space Man- 
agement. 

Referring to the drawings In detail, in Rgure 1 
a Data Access System 14 is illustrated in terms of 
the functions of its subcomponents, the relation- 
ships between its subcomponents, and its relation- 
ships with other components of a RIe Access Pro- 
cessor 12. 

The Data Access System 14 is described and 
claimed in a copending application. The Data Ac- 
cess System 14 is one component of a RIe Access 
Processor 12, which also includes two other com- 
ponents, a Service System 16 and a Storage Ac- 
cess System 18. the functions of which are gen- 
erally known in existing computer systems, and are 
not described in detail herein, but their basic func- 
tions are described briefly to establish perspective. 

A RIe Access Processor 12 services requests 
from a set of Application Support Processors 10 
which can exist in a global network, with each 
Application Support Processor 10 sharing access 
to data in files stored by the RIe Access Processor 
12. Application Support Processors 10 may operate 
asynchronously, sharing the set of file resources 
managed by one or more RIe Access Processors 
12. Each Application Support Processor 10 also 
maintains therein an internal cache of file informa- 
tion to Improve performance by reducing commu- 
nications with the RIe Access Processor 12 for 
information about files. The RIe Access Processor 
12 provides the Application Support Processors 10 
with information for updating this cache, and also 
responds to normal file access requests. 

A RIe Access Processor 12 manages access 
to a set of data files and information about files 
held in flie directories. RIe directories allow for 
managing file collections, relate to each other hier- 
archically, and may be shared. The RIe Access 
Processor also maintains therein a set of catalogs, 
which are repositories of internal information in the 
RIe Access Processor for its own Internal use, and 
which are not available and accessible to Applica- 
tion Support Processors, as are the data files and 
directories. Some of the requests supported by the 
RIe Access Processor 1 2 are as follows: 

OPEN, READ. WRITE and CLOSE for file 
access. 
DELETE files. 
COPY files. 



GRANT and REVOKE authorization to 
files, 

CREATE and DELETE directories. 
OPEN, READ and CLOSE for directory 
5 access. 

RENAME files and directories. 
RELOCATE files from one directory to an- 
other, and 

ADMINISTER file storage for flies. 

10 

The primary functions of the RIe Access Pro- 
cessor 12 components are as follows. 

The Service System 16 provides environmen- 
tally dependent services for the processor 12, in- 

75 eluding the Initial receipt of requests, forwarding 
requests for file access, and dispatching and ac- 
tivation of the Data Access System 14 of the 
present invention. These activations persist through 
a set of file requests that represent a recoverable 

20 unit of work (defined as a work unit herein), which 
Is explicitly concluded by a commit or rollback 
request (back-out) or certain other Implicit termina- 
tions. 

The Data Access System 14 processes indivld- 

25 ual requests, and maintains a set of catalogs that 
contain control and descriptive information con- 
cerning the set of files managed by the RIe Access 
Processor 12. This Information Includes data file 
control, security, integrity, concurrency, inter-reia- 

30 tionship,' recovery, status, and control information. 
The Data Access System 14 also accumulates 
cache update information, representing changes to 
file descriptions and characteristics, that are forwar- 
ded to maintain current the data in the caches of 

35 the Application Support Processors. 

The Storage Access System 18 manages the 
data blocks that comprise the data files - mapping 
them to external storage devices, the set of records 
that comprise the catalogs, the set of locks that 

40 permit concurrency, and the grouping of work 
Items that represent recovery units. It maps access 
to physical data with minimal sensitivity to logical 
grouping or content. The Storage Access System 
18 runs in the same activation as the Data Access 

45 System 14 that invokes it. 

The Data Access System 14 Subcomponents 
have the following functions. 

The Session Management Subcomponent 20 is 
at the hierarchical top of Data Access System 14 

50 request processing. It receives requests through 
the Service System 16. It is the focal point of 
control and includes a set of fundamental services 
for response formulation. It determines which Re- 
quest Management Subcomponent 32 routine 

55 should be invoked to service the request and 
passes control to it. At the end of request process- 
ing, control Is passed back to the Session Manage- 
ment Subcomponent 20 to finish request process- 
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ing and forward the requested response. 

TTie Session Management Subcomponent pro- 
vides the primary routing and control functions for 
the Data Access System. In addition, it manages 
work units, supports deferred commit of worl<, sup- 
ports response buffer management and ordering, 
as well as initialization and termination of the Data 
Access System. A number of routines support the 
operation of Session Management. Some of these 
routines are also utilized by other subcomponents 
of the Data Access System as common services. 

Following are some of the service routines in- 
cluded in the Session Management Subcomponent 
20. 

Start-up routine 22 - to initialize Data Access 
System 1 4 control structures. 

Storage Pool routine 24 - to maintain and dis- 
pense working storage for control structures. The 
Pool Routine is a general Data Access System 
service for allocating and de-allocating control 
structures from large blocks of working storage. 
The routine supports allocating or deallocating sin- 
gle or multiple control structures of the same type 
(changed) with a single invocation. 

Response routine 26 - to assist Request Man- 
agement Subcomponent 32 routines in the building 
of response messages, and to assemble the re- 
sponse and cache update information into a prop- 
erly formatted response message. The Response 
routine has two aspects. 

1. It supplies a Getbuffer Service used 
throughout the Data Access System for providing 
buffers that hold response information. For this 
service, it not only supplies the buffers, but also 
implicitly accounts for them, accumulating lists of 
buffers acquired in preparation for assembling the 
response for the current request 

2. It builds the response to the current re- 
quest from several sources: 

a. It invokes the Cache Management RE- 
TRIEVE routine for finding all of the Cache Notifica- 
tion Records (CNRs) and placing them in buffers 
supplied by the Response Routine. 

b. It builds a locator list of buffers consist- 
ing of the CNR buffers, buffers allocated by the 
Getbuffer Service, and standard request diagnostic 
information. This locator list is sent to the Service 
System for return of the response to the requesting 
Application Support Processor. 



Work routine 28 - to coordinate and initiate 
processing required when a logical group of re- 
quests are "committed" or "rolled back", i.e. man- 
age activities at designated points of recovery 
(termination of a work unit). The Work routine 28 
supports the commit and rollback explicit requests 
as well as implicit commit and rollback conditions. 



For explicit requests, the Work routine 28 Is in- 
voked through the Request Management Subcom- 
ponent 32. To maintain consistency and integrity, 
actual catalog updates are deferred until the suc- 
5 cessful completion of the work unit. The Work 
routine 28 invokes: 

a. the Catalog Management Subcomponent 
36 to accomplish catalog updates based upon 
WRBs (Work Request Blocks) built by Request 

10 Management Subcomponent 32 routines. 

b. the Space Management Subcomponent 
34 to coordinate the update of the Space Catalog 
based upon WRBs built by Request Management 
32 routines, 

15 c. the Storage Access System 1 8 to commit 

changes to file blocks and catalogs. 

d. the Cache Management Subcomponent 
38 to store cache notification information (also con- 
tained in Work Request Blocks built by the Re- 

20 quest Management Subcomponent 32 routines). 

Terminate routine 30 - to clean up control 
structures at the conclusion of an activation of the 
Data Access System 14. The Terminate Routine 

25 manages the clean-up of storage and control struc- 
tures when service to a particular Application Sup- 
port Processor is ended. Terminations occur from 
implicit failures (communications between an Ap- 
plication Support Processor and a RIe Access Pro- 

30 cesser, deadlock on resources, etc.) and explicit 
actions (system operator forced, Application Sup- 
port Processor ended, etc.). Terminations are dis- 
covered upon initial entry into Session Manage- 
ment or at any other point when an activation of the 

35 Data Access System regains control after an in- 
vocation of either the Service System or the Stor- 
age Access System. Therefore the Terminate Rou- 
tine is a service that is invoked from many places 
in the Data Access System where other RIe Ac- 

40 cess Processor components are invoked. 

WRB Condense routine 31 supports reduction 
of multiple changes to the same catalog entry into 
a single change. The Data Access System utilizes 
several catalogs for managing file and directory 

45 information. Each entry in the Object Catalog, for 
example, contains descriptive and control informa- 
tion about a particular file. Work Request Blocks 
(WRBs) are used to save catalog change informa- 
tion from the time of file request processing until 

50 * the time that the work unit is committed. When 
multiple WRBs exist for the same catalog entry, 
they are condensed into a single WRB. This is 
important for two reasons: 

a. Reduction of the number of catalog up- 
55 date operations (performance). 

b. Support of a special Catalog Management 
routine called "In-flight Retrieval". When an Ap- 
plication Support Processor request requires re- 
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trieval of a particular catalog entry, the In-flight 
Retrieval routine of Catalog Management is first 
called upon to search through the chain of com- 
mitable WRBs for the current work unit to deter- 
mine if there is a WRB for the requested catalog 
entry. If there is. the WRB will contain complete 
information for that entry, including changes in- 
curred by the current work unit When a WRB is 
found, it is used to satisfy the retrieval request in 
lieu of retrieving the actual catalog entry. This 
permits processes In the current work unit to al- 
ways see current work unit catalog changes before 
they are committed (written in to the catalogs) and 
made available to other Application Support Pro- 
cessors. This is essential for contextual processing 
within a work unit. In order for In-flight Retrieval to 
support return of a single catalog entry image, all 
changes to that catalog entry must have been 
condensed to a single WRB. 

The Request Management Subcomponent 32 
includes routines, illustrated as R1 through R9 - 
although typically totaling thirty to forty routines. It 
utilizes the Catalog Management Subcomponent 36 
to access catalogs, the Space Management Sub- 
component 34 to manage logical space, and the 
Cache Management Subcomponent 38 for cache 
control processing. 

The Request Management Subcomponent 32 
builds and maintains WRBs (Work Request Blocks) 
which go to the Work routine 28 at commit time 
(successful completion of a work unit) to drive 
catalog and cache updates. 

The Request Management Subcomponent 32 
utilizes the Storage Access System 18 directly to 
engage or disengage one or more logical locks that 
represent commitments against files and catalogs. 
It also invokes the Storage Access System 18 to 
add, delete, and update data blocks associated 
with particular files according to the requirements 
of the current request. 

The Catalog Management Subcomponent 36 
builds the control structures required for invoking 
the Storage Access System 18 to access the set of 
catalogs that the Data Access System 14 utilizes 
for control information for its set of files. Following 
are the catalogs managed by the Catalog Manage- 
ment Subcomponent 36: 

a. Directory Catalog - each entry describes a 
named directory which is a collection of files. 

b. Object Catalog - contains an entry for 
each file, alias (alternate access to a file), and 
directory. Entries include names, hierarchical rela- 
tionships (for directories), containing directory, au- 
thorization, owner, status, file characteristics, and a 
list of data block identifiers that are used to access 
the actual data for the file. 



c. Authorization Catalog - contains Applica- 
tion Support Processor 10 authorizations for files 
and directories. 

d. Space Catalog - contains file space con- 
5 sumption limitations (number of file blocks) for 

each Application Support Processor 10. 

e. Lock Catalog • contains information about 
locks that carry over past the end of an Application 
Support Processor 10 processing session. 

10 

When requested to retrieve catalog information, 
the Catalog Management Subcomponent 36 first 
searches for possible changes made by the current 
work unit, but not yet written into the catalogs. This 
15 Is done by searching the Work Request Blocks that 
represent changes that have not been committed 
until the end of the work unit. 

The Space Management Subcomponent 34 
manages the logical space for an Application Sup- 
20 port Processor 10 represented by a FSCB (File 
Space Control Block), a local representation of the 
Space Catalog entry for the Application Support 
Processor 10. Requests that affect logical space 
consumption due to changes in the storage con- 
25 sumed by files accomplish space accounting 
through the Space Management Subcomponent 34. 

The Space Management Subcomponent 34 
uses the Catalog Management Subcomponent 36 
to access the Space Catalog. 
30 The Cache Management Subcomponent 38 is 

invoked by the Work routine 28 of the Session 
Management Subcomponent 20 at the successful 
completion of a work unit (commit) to update the 
cached data maintained by the Data Access Sys- 
35 tem 14. using information in Work Request Blocks 
(WRBs) built by the Request Management Sub- 
component 32 to establish which directories are to 
be supported in the cache for the current Applica- 
tion Support Processor 10. 
40 The Cache Management System 38 is de- 

scribed and disclosed in further detail in patent 
application (attorney's docket 6775). The purpose 
of the Cache Management System 38 is to collect 
a set (cache) of directory change information, re- 
45 presenting updates to file descriptions and char- 
acteristics, and periodically distribute them to Ap- 
plication Support Processors for updating of their 
local caches. These caches improve performance 
by reducing the occasion for going to a File Access 
50 Processor for file information. 

Application Support Processors permit files to 
be grouped in directories. A cache is kept for a 
particular directory whenever the Application Sup- 
port Processor "acquires" the directory. In connec- 
55 tion with acquiring a directory, the Application Sup- 
port Processor requests all information about the 
directory and its files from the File access Proces- 
sor. This information is used to initially load the 



8 



15 



EP 0 312 865 A2 



16 



Application Support Processor's local cache. Con- 
currently, the File Access Processor is notified that 
the Application Support Processor requires notifica- 
tion of all future changes that affect that directory. 
This change notification continues until the direc- 
tory is explicitly "released". 

Information for updating the local cache of the 
Application Support Processors accompanies 
(piggybacks on) normal response information that 
is retumed from Application Support Processor re- 
quests. Information for updating the cache includes 
such things as file names, file lengths, file status, 
and authorization. The cache change information 
appears in individual records called Cache Notifica- 
tion Records (CNRs). 

In order to manage cache notification informa- 
tion for Application Support Processors, the Data 
Access System must support the following func- 
tions: 

1. Record which directories have been ac- 
quired by particular Application Support Processors 
(Cache Management ACQUIRE operation). 

2. Recognize changes in directory and file 
descriptions that affect the cache. 

3. Record the directory changes and accu- 
mulate the change information until the appropriate 
time for sending it to the interested Application 
Support Processors for updating their local caches. 

4. Send the change information (CNRs) to 
the interested Application Support Processors. 

5. Remove change information that all inter- 
ested Application Support Processors have re- 
ceived. 

6. Release directories that Application Sup- 
port Processor have previously "acquired", but no 
longer require. 

The Request Management Subcomponent 32 
of the Data Access System supports the Cache 
Management functions in the following respects. 

1. Processes individual requests from the 
Application Support Processors, and recognizes 
particular requests that cause a directory to be 
acquired (begin to receive cache notifications) and 
invokes Cache Management to put that Application 
Support Processor on the list of those to be noti- 
fied for changes to that directory. 

2. Recognizes particular requests that cause 
change to the cache. Generally, these correspond 
to requests that also cause changes to the follow- 
ing system catalogs. Directory Catalog, Object 
Catalog, and Authorization Catalog. 

3. Builds a Work Request Block (WRB) for 
each catalog change and adds to it additional in- 
formation for Cache Management where cache no- 
tification is also required. The Work Request 
Blocks are used to hold this information until the 
end of the group of requests that comprise a work 



unit, whereupon the catalogs are updated and 
Cache Management is called upon to accumulate 
and store the cache notification information. 

5 Rgure 2 illustrates the major control structures 

of the Data Access System 1 4, and the following is 
a description of these major control structures. 

One Data Access System (DAS) Global Control 
structure 40 is provided on a permanent basis for 

10 the Data Access System 14. It is the anchor for 
global control structures, those that are shared by 
all activations of the Data. Access System 14. Since 
its associated control structures are shared in a 
multiprocessing environment, appropriate latches 

75 associated with each set of structures are provided 
for controlling concurrent access by participating 
activations. 

A separate Data Access System (DAS) Local 
Control structure 42 is created for each activation 

20 of the Data Access System 14. The Local structure 
42 is the basis for controlling the processing of the 
current request or set of requests from an Applica- 
tion Support Processor 10. It is the anchor for the 
Request Buffer 44 that is provided by the Service 

25 System 1 6 Processor, as well as response informa- 
tion built by one of the Request Management Sub- 
component 32 routines. It also contains status in- 
formation for request processing, and is the anchor 
for other control structures that are required to 

30 transfer control data between the subcomponents 
of the Data Access System 14 and with the Stor- 
age Access System 18. A DAS Local structure 42 
and its parts are created and are maintained only 
to the end of the current work unit, i.e. for the set 

35 of requests serviced by the current activation. At 
the completion of the work unit, the work is either 
committed or rolled back. 

The following are the primary control structures 
associated with the DAS Global structure. 

40 File Space Control Blocks 46 (FSCBs) are used 

to do space accounting for a particular Application 
Support Processor 10. It provides limits and warn- 
ing thresholds for the number of data blocks that 
may be consumed by the associated Application 

45 Support Processor 10. A File Space Control Block 
46 is built from a Space Catalog entry, and is the 
basis for updating the Space Catalog when the 
work unit is committed. RIe Space Control Blocks 
46 are accessed through a Hash Table 46 utilizing 
50 a unique identifier for each Application Support 
Processor 10. RIe Space Control Blocks 46 are 
managed by the Space Management Subcom- 
ponent 34. 

Directory Gate Blocks 50 (DGBs) are used to 

55 define directories that are currently maintained in 
the cache. Each Directory Gate Block 50 repre- 
sents a cached directory, and Is the anchor for 
change information about files in the directory. Di- 
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rectory Gate Blocks 50 are accessed through a 
Hash Table 52 hashing on a unique directory iden- 
tifier. Directory Gate Blocks 50 are managed by the 
Cache Management Subcomponent 38. 

Directory Change Refresh Blocks 54 (DCRBs) 
record the actual change information about files in 
a directory. They are used by all Data Access 
System 14 activations that have the associated 
directory cached for notifying respective Applica- 
tion Support Processors 10 of the changes. Direc- 
tory Change Refresh Blocks 54 are managed by 
the Cache Management Subcomponent 38. 

Catalog Locators 56 are used by each Data 
Access System 14 activation to identify the cata- 
logs when invoking the Storage Access System 18 
for catalog access through the Catalog Manage- 
ment Subcomponent 36. 

Storage Pool Anchors 58 are maintained for 
each type of storage pool 60, and provide a basis 
for fast access to unused storage blocks that may 
be allocated to a Data Access System 14 activa- 
tion. Storage pools exist for each major type of 
control structure in the Data Access System 14. 
The storage blocks are used to build new control 
structures. The storage pools 60 are managed by 
the Storage Pool routine 24 of the Session Man- 
agement Subcomponent 20. 

The major control structures associated with 
each DAS Local structure 42 are as follows. 

Directory Acquired Blocks 62 (DABs) represent 
each directory that a particular Application Support 
Processor 10 has acquired for cache purposes. 
They are managed by the Cache Management 
Subcomponent 38. 

Work Request Blocks 64 (WRBs) are used to 
retain control information concerning a particular 
request. The information is used for the following: 

a. Holding information read from catalogs, 

b. Holding catalog change information until 
catalogs are updated at the end of a work unit, 

c. Saving information for updating the cache 
at the conclusion of the work unit, 

d. Backout processing when the current re- 
quest processing fails, 

e. Searching for changes to catalogs that 
have not yet been written Into the catalogs. 

Two chains of Work Request Blocks are used: 

in-process Chain 64 - represents Work 
Request Blocks that are associated with 
processing the current request 
Commitable Chain 64-represents Work 
Request Blocks from previously complet- 
ed, but uncommitted requests. 

Work Request Blocks 64 are built by Request 
Management Subcomponent 32 routines and are 



utilized by the Catalog Management Subcom- 
ponent 36» the Space Management Subcomponent 
34 and the Cache Management Subcomponent 38. 
File Control Blocks 68 (FCBs) are used to 
5 retain information about open files. Application 
Support Processors 10 have available requests that 
can open files, retrieve information in them, and 
close them when completed. FSBs are used by 
some Request Management Subcomponent 32 

70 routines. 

Catalog Scan Blocks 70 (CSBs) contain in- 
formation needed to process a catalog retrieval 
scan. A CSB 70 is retained until the scan is closed. 
They are managed by the Catalog Management 

rs Subcomponent 36. 

The purpose of Space Management System of 
the present invention is to manage file space as- 
signed to each Application Support Processor, sup- 
porting the space management functions: adding 

20 space, deleting space, setting tiiresholds for limit 
warnings, querying space, charging space used, 
warning notifications, crediting space freed, and 
permitting file spaces to be shared by more than 
one Application Support Processor. The significant 

25 design characteristics include: 

a. On-line administration of file spaces. 

b. Capability for sharing file space between 
multiple concurrent Application Support Proces- 
sors. The Space Management System allows 

30 Space Catalog change coordination between con- 
tending Application Support Processors in such a 
manner as to maximize concurrency. 

c. Capability for on-line query of file space 
status as of the last completed work unit without 

35 requiring a separate utility function. 

RIe space is assigned to Application Support 
Processors 10 by those authorized as administra- 
tors. It is consumed as files are created or ex- 
40 panded and reduced as they are deleted or con- 
tracted. 

Space management information is permanentiy 
recorded in tine Space Catalog 74, Rgure 3, which 
contains a record for each Application Support Pro- 

45 cesser 10, This record represents a logical file 
space that is assigned to each Application Support 
Processor. This record is updated when committing 
a work unit that impacts the file space. When a 
work unit is in progress, file space management 

50 information is kept in non-permanent storage in a 
File Space Control Block 46 (FSCB). 

An FSCB 46 is initially built from a Space 
Catalog record when a work unit is begun for an 
Application Support Processor. A local activation of 

55 the Data Access System is initiated to service the 
requests of the Application Support Processor for 
File Access Processor 12 work. Since an Applica- 
tion Support Processor may authorize another Ap- 

10 



19 



EP 0 312 865 A2 



20 



plication Support Processor to share its file space, 
the FSCBs that represents file spaces are global to, 
and potentially shared by, Data Access System 
activations. If the owning Application Support Pro- 
cessor is not active, FSCB creation may also be 
initiated by a sharing Application Support Proces- 
sor when it initiates space consumption activity for 
the shared file space. When an Application Support 
Processor Initiates file space consumption: 

a. In its own file space, the FSCB created 
during activation initiation is utilized for space man- 
agement; and 

b, in a file space owned by another Applica- 
tion Support Processor, it utilizes the FSCB created 
during the activation of the owning Application Sup- 
port Processor. If the owner is not active, an FSCB 
is created by the first non-owner that utilizes the 
file space. 

Figure 3 illustrates the set of control structures 
that are relevant to Space Management. 

FSCBs 46 are anchored to, and may be lo- 
cated from. FSCB Hash Table 48 entries. The 
FSCB Hash Table is located in the Global Control 
structure 40. The Hash Table Entry is determined 
from a hashing algorithm applied to the owning 
Application Support Processor ID, The set of syn- 
onym FSCBs (assigned to the same data location) 
represented by collisions in hashing are chained 
from the associated FSCB Hash Table Entry, 

An FSCB may also be found through a locator 
from the owning Application Support Processor's 
DAS Local Control 42 where the locator is stored 
during initialization of the DAS activation. 

Logically, an FSCB is no longer needed after a 
work unit is committed and it has been used to 
update the Space Catalog record. However: 

a. it is more efficient to avoid releasing it 
when there is a good possibility that it will be 
needed again by another work unit. Such is the 
case when the owner commits Its work unit: and 

b. it is necessary to avoid releasing it when 
there exists an active work unit initiated by a shar- 
ing Application Support Processor. 

To support these conditions, an Activity Coun- 
ter is maintained in each FSCB, see Figure 4, The 
Activity Counter is incremented by one for each 
activity initiated that involves the FSCB (change in 
space consumption) and decremented by one for 
each committed or terminated activity. The FSCB 
is released only when its Activity Counter goes to 
zero. The Activity Counter is incremented when the 
FSCB is created for the initiation of the owning 
Application Support Processor's Data Access Sys- 
tem activation and decremented when it termi- 
nates. It is also incremented when each new file is 
created or accessed for writing, then decremented 



when the file activity is committed or terminated. 
This retains the FSCBs while they are expected to 
be reused or currently active. 

A File Control Block (FCB) 68 is used to retain 

5 information about a particular file while it is being 
accessed by a local activation of an Application 
Support Processor. It has some particular fields for 
Space Management, including a locator for the 
FSCB that is set when the file access is initiated 

70 and used for rapid reference to the FSCB there- 
after. 

When a particular file access is completed 
successfully, a Work Request Block (WRB) 64 is 
built Certain information is transferred from the File 

75 Control Block 68 to the Work Request Block 64. 
and then the File Control Block is released. Work 
Request Blocks are used to retain information that 
Is needed to update the Object Catalog (changes in 
file information) and the Space Catalog (changes in 

20 space management information) when the work unit 
is successfully completed (committed). A separate 
WRB 64 is provided for each record in each cata- 
log that must be updated. 

UNDO Lists 76 are used to save the status of 

25 FSCBs at the beginning of the current work unit so 
that they can be restored in the event of a failure in 
updating the Space Catalog 74 during commit pro- 
cessing. 

Figure 4 shows pertinent fields for space man- 
30 agement in the FSCB 46, FCB 68. WRB 64, and 
UNDO List 76. 

The following are FSCB 46 fields not yet dis- 
cussed: 

a. SPACE LIMIT is the total space permitted 
35 for files. This is checked when consumption is 
committed. The commit fails if the limit is ex- 
ceeded. It is incremented by the ADD-SPACE re- 
quest and decremented by the DELETE-SPACE 
request. 

40 b. SPACE THRESHOLD is a percentage of 

the SPACE LIMIT. It is checked by each file re- 
quest that affects space consumption for potential 
generation of a warning for the accessing Applica- 
tion Support Processor. It is changed by the 

45 CHANGE-THRESHOLD request. 

c. SPACE CURRENTLY CONSUMED is up- 
dated for each file request that affects space con- 
sumption and is utilized to determine if the SPACE 
THRESHOLD has been reached. 

50 d. SPACE COMMITTED is updated when the 

work unit is committed by applying the SPACE 
CONSUMED-CURRENT WORK UNIT from each 
WRB 64 that participated in the work unit. 

e. FSCB LATCH is used to synchronize 

55 changes to the Space Catalog. 

The following are pertinent fields in the FCB 

68. 
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a. SPACE CONSUMED-CURRENT RE- 
QUEST is the change In space consumption- caus- 
ed by the completion of the most recent request 
against the file represented by this FCB. 

b. SPACE CONSUMED-CURRENT WORK 
UNIT is the change in space consumption caused 
by aii changes to the file represented by this FCB 
in the cunrent work unit 

The following are pertinent fields in the WRB 

66. 

a. SPACE CONSUMED-CURRENT WORK 
UNIT- is the change in space consumption caused 
by all changes to the file represented by this WRB 
in the current work unit. 

b. REQUEST TYPE is an encoding of the 
type of request that caused the WRB generation. It 
is set by the REQUEST MANAGEMENT routine 
depending on the type of request that is processed 
(ADD-SPACE. DELETE-SPACE, CHANGE- 
THRESHOLD, or WRITE-SPACE). 

c. PARAMETER VALUE is used to hold the 
new SPACE LIMIT or SPACE THRESHOLD for 
ADD-SPACE, DELETE-SPACE, and CHANGE- 
THRESHOLD requests so that it is available for 
modifying the FSCB and Space Catalog at commit 
time. 

d. SPACE CATALOG RECORD is an image 
of the Space Catalog record. It is read into this 
area in preparation for selectively updating it. 

The following are pertinent fields in the UNDO 
List 76. 

a. REQUEST TYPE is the type of request 
that caused the commit processing 

b. SPACE CURRENTLY CONSUMED is the 
accumulated value of aii SPACE-WRITE consump- 
tion for the associated FSCB for the current work 
unit 

c. SAVE VALUE is the value of SPACE UM- 
IT (for ADD-SPACE or DELETE-SPACE). SPACE 
THRESHOLD (for CHANGE-THRESHOLD) or 
SPACE COMMITTED (for SPACE-WRITE) in the 
FSCB before applying the changes associated with 
the current work unit. 

d. ACTIVrrY COUNT is the total changes to 
the ACTIVITY COUNT for the associated FSCB 
due to the changes applied for the current work 
unit 

Figure 5 illustrates the flow of control and data 
that occurs at the completion of a work unit 
(commit or rollback). 

The Space Management System of the present 
invention is designed to minimize the periods of 
non-concurrency for multiple Application Support 
Processor participating in updates to separate files 
in a file space. In this system write locks are 



utilized to prevent concurrent changes to the same 
file. However, concurrent changes to different files 
in a file space are allowed except during the period 
of Space Catalog update and commit of a work 

s unit The Space Management System is designed 
to allow Space Catalog change coordination be- 
tween contending Application Support Processors 
in such a manner as to maximize concurrency. 
The Space Management System accomplishes 

70 these system objectives by the sequence of oper- 
ations at commit time as illustrated in Rgure 5. 
Initially, all catalogs are updated except the Space 
Catalog. Write locks exist on individual files, and 
are held until the commit is completed. A commit 

75 latch on an FSCB serializes commits of Space 
Catalog changes. The FSCB latch is only held 
while doing the commit call to the Space Access 
System, thereby minimizing the period of non- 
concurrency for writers to a particular file space. 
20 The basic sequence of operations at commit 

time is illustrated in Rgure 5, and is: 

a. Update all catalogs except the Space 
Catalog. 

b. Update the Space Catalog from FSCBs, 
25 latching the FSCBs. 

c. Invoke the Space Access System to com- 
mit the catalog and file changes. 

d. Release the FSCB latch. 

30 This results in minimizing the period of non- 

concurrency for multiple Application Support Pro- 
cessors participating in updates to separate files in 
a file space. Reference is now made to the particu- 
lar sequence of steps illusti-ated in Figure 5, 

35 1. Request Management 32 routines that 

cause changes in file space consumption build 
WRBs containing information required for updating 
FSCBs and Space Catalog records.. These WRBs 
accumulate until the completion of tiie work unit 

40 2. At the completion of the work unit, the 

Work Routine of Session Management 20 pro- 
cesses successful (commit) or unsuccessful 
(rollback) work. For the commit of space manage- 
ment this involves coordinated update of the FSCB 

45 and the corresponding Space Catalog records for 
which other Application Support Processors may 
concurrently have outstanding work units. For roll- 
back of space management, the Space Manage- 
ment 34 Rollback operation is invoked to restore 

50 the FSCB SPACE CURRENTLY CONSUMED field 
to the value at the beginning of the work unit 

3. In addition to Space Catalog changes, the 
WRBs also cause updates to the Object Catalog 
(file characteristic and description changes). The 

55 Work Routine 28 invokes Catalog Management 36 
to make these changes to the Object Catalog. 
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4. If there is an error in the update of the 
Object Catalog » the Storage Access Processor 18 
does rollback processing to reverse all catalog and 
file changes for the current work unit. 

5. In addition, such an error causes invoca- s 
tion of Space Management 34 to restore the origi- 
nal value of SPACE CURRENTLY CONSUMED in 

the FSCBs (Rollback operation In Space Manage- 
ment), and the Work Routine commit processing is 
terminated. w 

6. With the successful update of the Object 
Catalog, Space Management 34 is invoked to up- 
date the Space Catalog. This is done by a Commit 
operation of Space Management. 

7. If there is a failure in the Space Manage- 75 
ment Commit operation, the Storage Access Sys- 
tem 18 must rollback ail catalog changes and the 
Work Routine 28 commit processing is terminated. 

8. The Storage Access System 18 is invoked 

to commit all of the catalog changes and file 20 
changes for the current work unit. 

9. If the Storage Access System 18 commit 
for the current work unit fails, the Space Manage- 
ment 34 UNDO operation is invoked to backout any 
changes to the FSCB made for the current work 25 
unit. FSCB latches are also released. 

10. If commit processing is successful, the 
Space Management 34 UNLATCH operation is in- 
voked to release latches on FSCBs. Latches are 
acquired by the Space Management COMMIT op- 30 
eration and held during Storage Access Processor 

1 8 commit to ensure that another Application Sup- 
port Processor does not attempt to use the FSCBs 
to commit its work unit until the current work unit 
commit is completed. 35 

11. The Space Management 34 COMMIT 
operation processes ali WRBs for the current work 
unit that have recorded space management 
changes. 

12. Before applying changes to the FSCB, 4o 
the FSCB latch is acquired and the status of the 
FSCB is saved in the UNDO List 76 so that it can 

be restored in the event of a failure. The UNDO 
List is also used to indicate which FSCBs have 
been latched for the commit. 45 

13. The WRB changes are applied to the 
corresponding FSCBs. 

■ 14. Catalog Management 36 Is invoked to 
update the Space Catalog 74 accordingly. 

15. TFie Space Management 34 Unlatch op- so 
eration releases latches for each FSCB that is 
represented in the UNDO List. 

16. The Space Management 34 UNDO op- 
eration processes the UNDO List, releasing latches 

and restoring ail FSCBs to their status before the 55 
work unit began. 



17. The Space Management 34 Rollback op- 
eration uses the SPACE CONSUMED-CURRENT 
WORK UNIT in either the WRBs or FCBs to back 
out the affect of the current work. unit on the 
SPACE CURRENTLY CONSUMED field in the cor- 
responding FSCBs. FCBs apply for those cases 
where no WRB had been created from the FOB at 
the time of the failure. 

Latches are mechanisms which provide serial- 
ization between multiple Data Access System ac- 
tivations that may operate concurrently. The follow- 
ing two types of latches are used in Space Man- 
agement: 

The Hash Table Entry Latch - which syn- 
chronizes the following for a particular syn- 
onym chain of FSCBs: searching for 
FSCBs, adding FSCBs. deleting FSCBs, 
changing the ACTIVITY COUNT for an 
FSCB in the chain, and changing SPACE 
CURRENTLY CONSUMED for an FSCB in 
the chain. 

The FSCB Latch - which synchronizes 
Space Catalog updates, preventing other 
activations from doing likewise for the 
latched FSCB until the commit by the 
latching activation is complete. When mul- 
tiple FSCBs are involved in a single com- 
mit, latches are acquired for the FSCBs. 
and Space Catalog updates occur In an 
order dictated by their respective Applica- 
tion Support Processor ID values. This 
assures that deadlocks between sharing 
activations are prevented. 

When both types of latches are required con- 
currently, . the Hash Table Entry Latch is acquired 
first to prevent deadlocks. 

The following operations are supported by 
Space Management 34. the more complicated of 
which are illustrated in the logic flow diagrams of 
Figures 6 through 11: 



1. ADD-SPACE 

This operation adds to the file space permitted 
for the specified Application Support Processor. 
Input is the Application Support Processor ID and 
the space quantity increment. 

Build a WRB for the request 
Set the REQUEST TYPE to ADD-SPACE. 
Store the Application Support Processor 
ID. . 

Put the space quantity increment value in 
the PARAMETER VALUE field. 
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Put the WRB in the chained list for pro- 
cessing at the end of the work unit. 



5 

2. DELETE SPACE 

This operation reduces file space permitted for 
the specified Application Support Processor, Input 
is the Application Support Processor ID and the w 
space quantity for reduction. 

Processing is about the same as for ADD- 
SPACE except the REQUEST TYPE is 
DELETE-SPACE. 75 



3, CHANGE-THRESHOLD 

20 

This operation changes the threshold value for 
the file space, changing the point at which war- 
nings will occur. Input is the new threshold percent- 
age and the Application Support Processor ID. 

25 

Build a WRB for the request 
Set the REQUEST TYPE to CHANGE- 
THRESHOLD. 

Store the Application Support Processor 
ID. 30 
Put the new threshold value in the PA- 
RAMETER VALUE field. 
Put the WRB in the chained list for pro- 
cessing at the end of the work unit. 

35 



4. CHECK-THRESHOLD 

This operation updates' the SPACE CURRENT- 40 
LY CONSUMED field of the FSCB and returns an 
indicator if the threshold has been reached. Input is 
the Application Support Processor ID. the change 
value, and an FCB locator. 

45 

Hash the Application Support Processor ID 
to determine the Hash Table Entry. 
Acquire the latch for the Hash Table Entry. 
Add the SPACE CONSUMED-GURRENT 
REQUEST of the FCB to the SPACE CUR- so 
RENTLY CONSUMED of the FSCB. 
If SPACE CURRENTLY CONSUMED = 
the product of the SPACE THRESHOLD 
and the SPACE LIMIT, then return a warn- 
ing indicator. 55 
Add SPACE CONSUMED-CURRENT RE- 
QUEST to SPACE CONSUMED-CUR- 
RENT WORK UNIT.- 



Release the latch on the Hash Table Entry, 



5. QUERY-SPACE 

This operation retums information from the 
Space Catalog for the specified Application Sup- 
port Processor. Information includes SPACE LIMIT, 
SPACE THRESHOLD, and SPACE COMMITTED. 

Read the appropriate Space Catalog 
record. 

Return the information from the record. 



6. CREATE-FSCB 

This operation attempts to find an existing 
FSCB for the specified Application Support Proces- 
sor. If an existing FSCB is found, the ACTIVITY 
COUNT is incremented by one. If an existing FSCB 
in not found, an FSCB is created. Input is an 
Application Support Processor ID. An FSCB locator 
is returned. 

Hash the Application Support Processor ID 

to get the Hash Table Entry. 

Acquire the latch for the hash Table Entry, 

Search for the FSCB for the Application 

Support Processor in Hash Table synonym 

chain. 

If FSCB not found: 

Read the Space Catalog record for the 
Application Support Processors file space. 
Build an FSCB from the Space Catalog 
record. Set the ACTIVITY COUNT to one. 
Put the FSCB in the Hash Table synonym 
chain. 

If FSCB found, increment ACTIVITY 
COUNT by one. 

Release the latch on the Hash Table Entry. 
Return the locator to the FSCB. 



7. ACQUIRE-FSCB 

This operation uses an FSCB locator to go 
directly to an FSCB and increments its ACTIVITY 
COUNT by one. Input is an FSCB locator. The 
operator is used in lieu of CREATE FSCB when the 
locator is known. 

Use the Application Support Processor ID 
in the FSCB located using the input pa- 
rameter locator to hash to an FSCB Hash 



14 



27 



EP 0 312 865 A2 



28 



Table Entry. 

Acquire a latch for the Hash Table Entry. 
Increment the ACTIVITY COUNT of the 
FSCB by one. 

Release the latch for the Hash Table En- 
try. 



8. RELEASE-FSCB 

This operation releases the current FSCB from 
the Data Access System. There is no input. The 
FSCB locator from the current DAS Local Control is 
used. 

Use the Application Support Processor ID 
In the FSCB located using the input pa- 
rameter locator to hash to an FSCB Hash 
Table Entry. 

Acquire a latch for the Hash Table Entry. 
Decrement the ACTIVITY COUNT of the 
FSCB by one. . 

If the ACTIVITY COUNT is zero, release 
the FSCB from the Data Access System, 
unchain it. and make it available for reuse. 
Release the latch for the Hash Table En- 
try. 



9. COMMIT 

This operation applies changes for the current 
work unit to the FSCB and uses the changes to 
update the corresponding Space Catalog records. 
Input is a chained list of WRBs containing file 
space change Information. Figures 6, 7 and 8, 
when placed together with Figure 6 on top. Figure 
7 in the middle, and Figure 8 on the bottom, 
illustrate a logic flow diagram of the COMMIT op- 
eration supported by Space Management 34 and 
explained hereinbelow. 

Order all WRBs by the Application Support 

Processor ID. 

Process each WRB in the order; for each: 
If REQUEST TYPE = ADD-SPACE. 
DELETE-SPACE. or CHANGE-THRESH- 
OLD, then invoke CREATE-FSCB (for the 
WRITE-SPACE requests, this will have 
been done by a file access routine of 
Request Management 32 when the file 
was first accessed). 

If this is the first WRB for the Application 
Support Processor ID. then: 

a. Hash the Application Support Processor 
ID to determine the FSCB Hash Table entry. 



b. Acquire the FSCB latch. 

c. Save the FSCB Locator. REQUEST TYPE, 
and Application Support Processor ID in the UNDO 
List from the corresponding values for the asso- 

5 dated FSCB. 

d. If the REQUEST TYPE IS ADD-SPACE or 
DELETE-SPACE. then store the FSCB SPACE 
LIMIT in the SAVE VALUE field of the UNDO Ust. 

e. If the REQUEST TYPE IS CHANGE- 
10 THRESHOLD, then store the FSCB SPACE 

THRESHOLD in the SAVE VALUE field of the 
UNDO List. 

f. If the REQUEST TYPE IS WRITE-SPACE. 
then store the FSCB SPACE COMMITTED in the 

15 SAVE VALUE field of the UNDO List. 

Add one to the ACTIVITY COUNT in the 
UNDO List. . 

If REQUEST TYPE is ADD-STORAGE. 
20 then increment the SPACE LIMIT in the 

F^SCB by the value of the PARAMETER 
VALUE in the WRB. 

If REQUEST TYPE is DELETE-STORAGE. 

then decrement the SPACE LIMIT in the 
25 FSCB by the value of the PARAMETER 

VALUE in the WRB 

If REQUEST TYPE is CHANGE-THRESH- 
OLD, then replace the SPACE THRESH- 
OLD in the FSCB with the value of the 
30 PARAMETER VALUE in the WRB. 

If REQUEST TYPE IS WRITE-SPACE. 
then: 

a. Add the SPACE CONSUMED-CURRENT 
35 WORK UNIT of the WRB to the SPACE COMMIT- 
TED of the FSCB and the SPACE CURRENTLY 
CONSUMED Of the UNDO List. 

b. If SPACE COMMITTED Of the FSCB is 
greater than SPACE LIMIT of the FSCB. then set 

40 the error indicator. 

c. If this is the last WRB for an Application 
Support Processor ID. update the Space Catalog 
record with the changed values from the corre- 
sponding FSCB, 



45 



50 



If the error indicator is set. then invoke the 
UNDO operation. 



10. ROLLBACK 

This operation reverses updates to the SPACE 
CURRENTLY CONSUMED field of all FSCBs asse- 
ss dated with the current work unit WRBs and FCBs 
for the current work unit are used as input. Figure 9 
illustrates a logic flow diagram of the ROLLBACK 
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operation supported by Space Management 34 and 
explained hereinbelow. 

Process all FCBs for the work unit 

a. Use FSCB LOCATOR in the FOB to get 

the Application Support Processor ID. s 

b. Hash it to the Hash Table Entry. 

c. Acquire the Hash Table Entry latch. 

d. Reduce the ACTIVITY COUNT in the 
FSCB by one. 

e. If the ACTIVITY COUNT is zero, release w 
the FSCB. 

f. If the activity count is not zero. reduce the 
SPACE CURRENTLY CONSUMED in the FSCB by 
the value in the SPACE CONSUMED-CURRENT 
WORK UNIT of the FCB. ,5 

g. Release the latch on the Hash Table En- 
try. 

Process all WRBs for the work unit: 

a. Use FSCB LOCATOR in the WRB to get 20 
the Application Support Processor ID. 

b. Hash it to the Hash Table Entry. 

c. Acquire the Hash Table Entry Latch. 

d. Reduce the ACTIVITY COUNT In the 
FSCB by one. 25 

e. If the ACTIVITY COUNT is zero, release 
the FSCB. 

f. If the ACTIVITY COUNT is not zero, re- 
duce the SPACE CURRENTLY CONSUMED in the 
FSCB by the value in the SPACE CONSUMED- 30 
CURRENT WORK UNIT of the WRB. 

g. Release the latch on the Hash Table En- 
try. 
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11. UNDO 

This operation reverses all changes to FSCBs 
for the current work unit, reduces the ACTIVITY 4o 
COUNT for FSCBs, and releases the latches on the 
FSCBs. Input is an UNDO List. Figure 10 illustrates 
a logic flow diagram of the UNDO operation sup- 
ported by Space Management 34 and explained 
hereinbelow. 45 
Process each element of the UNDO List: 
Hash the Application Support Processor 
ID. 

Acquire the Hash Table Entry Latch. 

If REQUEST TYPE is WRITE-SPACE. then so 

a. Restore SPACE COMMITTED in the 
FSCB with the SAVE VALUE of the UNDO entry. 

b. Reduce SPACE CURRENTLY CON- 
SUMED in the FSCB by the value of SPACE CUR- 55 
RENTLY CONSUMED in the UNDO entry. 

if REQUEST TYPE is ADD-SPACE or 



DELETE-SPACE. then Restore SPACE 
LIMIT in the FSCB with the SAVE VALUE 
of the UNDO entry. 

If REQUEST TYPE is CHANGE-THRESH- 
OLD, then Restore SPACE THRESHOLD 
in the FSCB with the SAVE VALUE of the 
UNDO entry. 

Reduce ACTIVITY COUNT in the FSCB by 
the value of the ACTIVITY COUNT in the 
UNDO entry. 

If the ACTIVITY COUNT is zero, release 
the FSCB, unchaining it, and making it 
available for reuse. 

If the ACTIVITY COUNT is not zero, then 
proceed. 

Release the FSCB Latch. 

Release the latch on the FSCB Hash Table 

Entry. 



12. UNLATCH 

This operation release latches on all FSCBs for 
which latches were acquired in the current work 
unit and reduces the ACTIVITY COUNT for the 
FSCBs. Figure 11 illustrates a logic flow diagram of 
the UNLATCH operation supported by Space Man- 
agement 34 and explained hereinbelow. 

Process each element of the UNDO List: 
Hash the Application Support Processor 
ID. 

Acquire the Hash Table Entry Latch. 
Reduce ACTIVITY COUNT in the FSCB by 
the value of the ACTIVITY COUNT in the 
UNDO entry. 

If the ACTIVITY COUNT is zero, release 
the FSCB. unchaining It and making It 
available for reuse. 

If the ACTIVITY COUNT in the FSCB is 
not zero, then proceed. Release the FSCB 
Latch. 

Release the Latch on the FSCB Hash Ta- 
ble Entry. 



Claims 

1. A space management system of a data 
access system (14) for a file access processor (12) 
which services requests regarding data in files, 
such as copy, delete, open and close files, from a 
plurality of application support processors (10), with 
the data access system managing shared access 
to data files and information about files contained in 
file directorieSr said space management system 
managing file space assigned to each application 
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support processor and supporting the space man- 
agement functions of, adding space, deleting 
space, setting thresholds for (Imit warnings, 
querying space, charging space used, warning no- 
tifications, crediting space freed, and permitting file s 
spaces to be shared by more than one application 
support processor, and comprising: 

a. a space catalog for recording therein a 
record for each application support processor re- 

. presenting logical file space that is assigned to io 
each application support processor; 

b. said data access system including a glo- 
bal control structure which Is maintained perma- 
nently for all activations of the data access system 
(14), and wherein said global control structure pro- ts 
vides a basis for locating file space control blocks 
which maintain file space information in temporary 
storage, each said file space control block being 
Initially built from a space catalog record when a 
work unit is initiated for a particular application 20 
support processor; and 

c. said data access system updating the 
record in said space catalog for the particular ap- 
plication support processor when the work unit is 
finished and committed. 25 

2. A space management system for a data 
access system as claimed in claim 1, wherein 
multiple application support processors can con- 
sume space in a file space concurrently, and said 30 
data access system and space management sys- 
tem support the on-line administration of a com- 
mon set of space consumption limits and thresh- 
olds. 

3. A space management system for a data 55 
access system as claimed in claim 2, wherein the 
space management system minimizes periods of 
non-concurrency for multiple application support 
processors participating in updates to separate files 

in a file space, in which write locks are utilized to 40 
prevent concurrent changes to the same file, and 
wherein concurrent changes to different files in a 
file space are allowed except during the period of 
updating the space catalog and commiting of a 
work unit. 45 

4. A space management system for a data 
access system as claimed in claim 3, wherein the 
space management system allows space catalog 
change coordination between contending applica- 
tion support processors in such a manner as to so 
maximize concurrency by the sequence of oper- 
ations at commit time. In which all catalogs are 
Initially updated except the space catalog, and 
write locks exist on individual files and are held 

until the commit is completed, a commit latch on a 55 
file space control block (46) serializes commits of 
changes of the space catalog, and the file space 
control block latch is held only during the commit 



call to a space access system, thereby minimizing 
the period of non-concurrency for writers to a par- 
ticular file space. 

5. A space management system for a data 
access system as claimed in claim 2. wherein an 
application support processor can authorize an- 
other application support processor to share its file 
space, and when an application support processor 
initiates file space consumption in its own file 
space, the file space control block created during 
activation initiation is utilized for space manage- 
ment, and when file space consumption is In a file 
space owned by another application support pro- 
cessor, the initiating application support processor 
utilizes the file space control block (46)created 
during the activation of the owning application sup- 
port processor, and If the owner is not active, a file 
space control block is created by the first non- 
owner that utilizes the file space. 

6. A space management system for a data 
access system as claimed in claim 1, wherein the 
file space control block (46) for an application sup- 
port processor includes fields for, space limit which 
is the total space permitted for files, space thresh- 
old which is a percentage of the space limit, space 
currently consumed which is updated for each file 
request that affects space consumption and is uti- 
lized to determine if the space threshold has been 
reached, space commited which is updated when 
the work unit is committed, and file space control 
block latch which is used to synchronize changes 
to the space catalog. 

7. A space management system for a data 
access system as claimed in claim 1, wherein for 
controlling the release of a file space control block, 
an activity counter is maintained in each file space 
control block which is incremented by one for each 
activity initiated that involves a change in space 
consumption and decremented by one for each 
committed or terminated activity of that file space 
.control block, and wherein the file space control 
block Is released only when its activity counter 
goes to zero, which retains the file space control 
block while it is expected to be reused or currently 
active. 

8. A space management system for a data 
access system as claimed in claim 1 , wherein said 
global control structure includes a file space control 
block hash table in which a file space control block 
of a particular application support processor can be 
located. 

9. A space management system for a data 
access system as claimed in claim 1 , wherein said 
data access system further includes local control 
(42) structures, one for each activation of the data 
access system by a particular application support 
processor, and the local control structure provides 
a basis for locating a file control block which is 
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used to retain information about a particular file 
while it is being accessed by a local activation of 
an application support processor, and has particu- 
lar fields for space management, including a lo- 
cator for the file space control block that is set 
when the file access Is initiated and used for rapid 
reference to the file space control block thereafter. 

10. A space management system for a data 
access system as claimed in claim 9, wherein the 
file control block also includes fields for space 
consumed-current request which is the change in 
space consumption caused by the completion of 
the most recent request against the file repre- 
sented by this file control block, and space 
consumed-current work unit which is the change in 
space consumption caused by ail changes to the 
file represented by this file control block in the 
current work unit 

11. A space management system for a data 
access system as claimed in claim 9, wherein, 
when a particular file access is completed success- 
fully, a work request block is accessed containing 
information required for updating file space control 
blocks and the space catalog records, and informa- 
tion is transferred from the file control block to the 
work request block, and then the file control block 
is released, said work request block being used to 
retain information that is needed to update the 
space catalog on changes in space management 
information when the work unit is successfully com- 
pleted and committed, and wherein a separate 
work request block (64) is provided for each record 
in each catalog that must be updated. 

12. A space management system for a data 
access system as claimed in claim 11, wherein the 
work request block includes fields for. space 
consumed-current work unit which is the change in 
space consumption caused by all changes to the 
file represented by this work request block in the 
cunrent work unit, request type which is an encod- 
ing of the type of request that caused the work 
request block generation, parameter value which is 
used to hold the new space limit or space thresh- 
old for add-space. delete-space, and change- 
threshold requests so that it is available for modify- 
ing the file space control block (46) and space 
catalog at commit time, and space catalog record 
which is a copy of the space catalog record read 
into this area in preparation for selectively updating 
it 

13. A space management system for a data 
access system as claimed in claim 1, wherein said 
local control structure provides a basis for locating 
UNDO Lists which are used to save the status of 
file space control blocks at the beginning of the 
current work unit so that the file space control 
blocks can be restored in the event of a failure in 



updating the space catalog during commit process- 
ing. 
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SESSION MANAGEMENT 20 



WORK ROUTINE (ROLLBACK): ROUTE- 
WORK ROUTINE (COMMIT): 
-ROUTE (3)- 



- IF ERROR— 
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FIG. 5 



SPACE MANAGEMENT END OF WORK UNIT PROCESSING 
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* ORDER ALL WRBs BY THE APPLICATION SUPPORT PROCESSOR ID 



I 



* PROCESS EACH WRB IN THE ORDER; FOR EACH: 




* INVOKE CREATE- FSCB (FOR WRITE 
REQUESTS, THIS WILL HAVE BEEN 
DONE BY A FILE ACCESS ROUTINE 
OF REQUEST MANAGEMENT WHEN 
A FILE IS FIRST ACCESSED.) 



HASH THE APPLICATION PROCESSOR ID 
TO DETERMINE THE FSCB HASH TABLE 
ENTRY. 

ACQUIRE THE FSCB LATCH 
SAVE THE FSCB LOCATOR, REQUEST 
TYPE, AND APPLICATION SUPPORT 
PROCESSOR OD ON THE UNDO LIST 
FROM THE CORRESPONDING VALUES 
FOR THE ASSOCIATED FSCB. 



0 




* STORE FSCB LIMIT 
IN THE SAVE VALUE 
FIELD OF THE 
UNDO LIST. 



* STORE FSCB SPACE 
THRESHOLD IN 
THE SAVE VALUE 
FIELD OF THE 
UNDO LIST. 



© 



FIG. 6 COMMIT OPERATION 



THIS PAGE BLANK (USPTO) 



EP 0 312 865 A2 



* PROCESS EACH ELEMENT OF THE UNDO LIST: 



* HASH THE APPLICATION SUPPORT PROCESSOR ID 

* ACQUIRE THE HASH TABLE ENTRY LATCH 

* REDUCE THE ACTIVITY COUNT IN THE FSCB BY THE VALUE 
OF THE ACTIVITY COUNT IN THE UNDO ENTRY 



ACTIVITY 
COUNT=0 



YES 



* RELEASE THE FSCB 
-UNCHAIN IT 

— MAKE IT AVAILABLE FOR REUSE 



NO 



•*• RELEASE THE FSCB LATCH 

* RELEASE THE LATCH ON THE FSCB HASH TABLE ENTRY. 



FIG.Il UNLATCH OPERATION 
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* PROCESS EACH ELEMENT OF THE UNDO LIST: 

i A^^m Jr^^,^''''^'^*"'"'^^ SUPPORT PROCESSOR !D 

* ACQUIRE THE HASH TABLE ENTRY LATCH 



REQUEST 
TYPE=WRITE- 
SPACE 



NO 



YES 



* RESTORE SPACE COMMITTED IN THE FSCB 
WITH THE SAVE VALUE OF THE UNDO 
ENTRY. 



* REDUCE SPACE CURRENTLY CONSUMED 
IN THE FSCB BY THE VALUE OF SPACE 
CURRENTLY CONSUMED IN THE UNDO 
EN I RY. 



REQUEST TYPE = 
ADD-SPACE OR 
DELETE- SPACE 



YES 



* RESTORE SPACE LIMIT IN THE FSCB WITH 
THE SAVE VALUE OF THE UNDO ENTRY. 



NO 



REQUEST 
TYPE = CHANGE- 
THRESHOLD 




* RESTORE SPACE THRESHOLD IN THE 
FSCB WITH THE SAVE VALUE OF THE 
UNDO ENTRY. 



NO 



* aI^VwEJ^^ ACTIVITY COUNT IN THE FSCB BY THE VALUE OF THF 
I ACTIVITY COUNT IN THE UNDO ENTRY. VAUUt OF THE 




* RELEASE THE FSCB 
-UNCHAIN IT 
.. -MAKE IT AVAILABLE FOR REUSE 



* RELEASE THE FSCB LATCH 

* RELEASE THE LATCH ON THE FSCB HASH TABLE ENTRY. 



FIG. 10 UNDO OPERATION 
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* PROCESS ALL FCBs FOR THE WORK UNIT: 

* USE FSCB LOCATOR IN THE FCB TO GET THF 
APPLICATION SUPPORT PROCESSOR ID 

* HASH IT TO THE HASH TABLE ENTRY 

* ACQUIRE THE HASH TABLE ENTRY LATCH 

* REDUCE THE ACTIVITY COUNT IN THE FSCB BY ONE 



ACTIVITY 
COUNT=0 



YES 



* RELEASE THE FSCB 
-UNCHAIN IT 

-MAKE IT AVAILABLE FOR REUSE ' 



* HFtHS^oJJI^^'^A^^ CURRENTLY CONSUMED IN THE FSCB BY THF vai hp 
IN THE SR^CE CONSUMED- CURRENT WORK UNIT OF THE FCB 



{•* RELEASE THE LATCH ON THE HASH TABLE ENTRY 



* PROCESS ALL WRBs FOR THE WORK UNIT: ' 

*USE FSCB LOCATOR IN THE WRB TO GET THE 
APPLICATION SUPPORT PROCESSOR ID 

* HASH IT TO THE HASH TABLE ENTRY 

* ACQUIRE THE HASH TABLE ENTRY LATCH 

* REDUCE THE ACTIVITY COUNT IN THE FSCB BY ONE 




* RELEASE THE FSCB 
-UNCHAIN IT 

-MAKE IT AVAILABLE FOR REUSE 



^flf^*^^^ THE SPACE CURRENTLY CONSUMED IN THE FSCB BY THF va, mp" 
IN THE SPACE CONSUMED- CURRENT WORK UNITOF THE WRB ^ 



I RELEASE THE LATCH ON THE HASH TABLE ENTRY 



FIG .9 ROLLBACK OPERATION 
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0 



© 



REQUEST 
TYPE IS WRITE- 
SPACE 



^ ADD THE SPACE CONSUMED-CURRENT 
WORK UNIT OF THE WRB TO THE 
SPACE COMMITTED OF THE FSCB AND 
THE SPACE CURRENTLY CONSUMED 
OF THE UNDO LIST. 




0 



LAST 



THIS 
WRB 



IS 



FOR 



AN APPLICATION 
SUPPORT 
PROCESSOR 
ID 



YES) 



^ SET ERROR 
INDICATOR 



NO 



* IF THE ERROR INDICATOR IS SET, THEN INVOKE THE UNDO OPERATION. 



FIG. 8 COMMIT OPERATION 
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* ADD ONE TO THE ACTIVITY COUNT IN THE UNDO LIST 



-* INCREMENT THE SPACE LIMIT IN THE 
i=3CB BY THE VALUE OF THE 
PARAMETER VALUE IN THE WRB. 



* DECREMENT THE SPACE LIMIT IN THE 
FSCB BY THE VALUE OF THE 
PARAMETER VALUE IN THE WRB. 



* REPLACE THE SPACE THRESHOLD IN 
THE FSCB BY THE VALUE OF THE 
PARAMETER VALUE IN THE WRB. 
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FIG. 7 COMMIT OPERATION 
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